Colvilles Ltd., Ravenscraig Steelworks A Short Description of the Leo3/32 Production Planning & Control System
Introduction Colvilles Ltd. Steelmakers installed a LEO III (No.32) in their Ravenscraig Works in Motherwell in 1963. In 2021, Dr. William (Bill) Jack, leader of the systems development team described in a paper to the LEO Computers Society the systems developed and run on this computer. I was the lead analyst on the Production Planning and Control system and was asked by the Society if I could provide further detail on how Lector OMR techniques were used. I was not involved in the concurrent development of the payroll system so my recollections are only of the PPC system. This request was made nearly 60 years after we had acquired the LEO and all documentation had long since been destroyed. We clearly did not have the foresight to realise that what we were developing could be regarded as pioneering.
Locating some lost information Perhaps a word is in order as to how I managed to get a little more detail. In 1967 I had just got married and was working on draft drawings of a house I planned to build. By pure chance, I recently found that one of these drawings had, on the back of it, most of a flow chart of the Production Planning & Control system that we had implemented. I think it is probably just missing 1 or 2 operations down one edge so it gives a very good picture of the scope of the system. It is unfortunately very faded and not really suitable for adding to the LEO archives. I was able to pick up much detail of the use of Lector documents from it but, regretfully, have not managed to trace any of the actual documents. This flow-chart, however, enabled me to extract further information about the system.
Why optical mark reading? The primary requirement of the system was to provide information as at 6am for day staff who started work at 8.30am and for production meetings at 9am. This was not possible to achieve using conventional data preparation.
Collection of order details Lector documents were used to collect data on new orders, order amendments, order cancellations and order completions. These documents were completed by sales personnel in an office environment. This information was input to the system run at 6am daily thus providing an updated order file.
Collection of steel movements and change of status As Dr. Jack explained in his paper, for process scheduling reasons, it was not possible, unless an order was very small, to move all of the material for it through the plant together. However, by tracking the movement of every piece of material, whether or not allocated to an order, the system could provide the requirements of every order and the present progress towards order completion including whether there was a shortfall of material for it.
Lector documents collected information on the creation of steel slabs, their dimensions and allocation to orders and the coil of steel produced from each slab. Thereafter, Lector documents were used to record every movement and change of status of a coil. In later processing, a coil could be cut along its length into 2 or more narrower ones. Coils could also be cut into bundles of sheets and further processed. Lector documents were also used to track material through these processes. Where a coil was despatched to Gartcosh Works finishing processes the tracking continued until despatch from there as either coils or bundles of sheets. The data recorded on each coilor bundle as it passed through the processes included a code for the process, any change to dimensions, any change to weight and any change to grade (which resulted in it being removed from its allocated order). A lector document was also used to collect information on surplus stock being allocated to suitable orders. The tracking of coil and sheet bundles movement thus covered all processes until the material was despatched.
The Lector documents were completed by recorders on the shop floor (see appendix 1). The data was collected through a 24 hour period and input to the Lector machines at Ravenscraig and Gartcosh. Trials showed that time was probably insufficient to get the Gartcosh Lector paper-tape output driven over to Ravenscraig after 6am. add it to the Ravenscraig data, complete the system run and get the Gartcosh print-outs delivered all before 8.30am. A paper-tape reader to paper-tape punch link was thus commissioned between Gartcosh and Ravenscraig.
The system produced production reports for morning progress and planning meetings at 9am. Additionally, order file reports were produced showing the present status of each order so that remedial action could be taken if it was running late or short of material. Lists were produced of the stock ahead of each production unit to assist schedulers with their work and to greatly simplify periodic stock checks. Subsequent stock-checks showed the system to be highly accurate.
Analysis of the recovered flow chart indicates that there were 52 Cleo routines providing vetting and files updating together with about 50 printed reports. There were upwards of 30 sort routines. I do not have actual figures but there must have been many hundreds of order and stock changes every 24 hours.
Development team Initially, the team comprised about 9 personnel who worked on systems analysis and the early stages of systems design. As work progressed, 6 of the team then programmed the analytical work. It seems remarkable that the system design and implementation was done by only about 3 systems analysts and 6 analyst-programmers using Cleo, which speaks highly of that language. The basic tracking and reporting system was implemented in late 1965 by the team that had only been trained early that year. However, continuous enhancements followed in the use of all the data that was being collected.
Further development Round about 1970, under a British Steel reorganisation, the Leo 3 was to be replaced by an IBM 360/40. It indicates how highly the Leo system was regarded that the suite of programs was rewritten almost unchanged in PL1 to run on the IBM machine. This rewritten system which was implemented in 1973 still used Lector documents for several years until replaced by on-line terminals.
Appendix 1 – Design of Lector forms Trial OMR documents were printed and tested out on shop-floor production recorders. Most of the data to be collected was numeric; items such as material identity, any changes to dimensions, weight, grade or anything else that could change at any specific production unit. Alpha data was very limited and normally restricted to one of several characters. The test documents had the particular processing unit identity pre-printed on them. As most of the date to be collected was numeric, each character of a particular parameter to be input was represented by four, what we called, soup-bowls labelled 1, 2, 3 and 6. Thus, by filling in no more than 2 of these soup-bowls by pencil, any digit from 0 to 9 could be represented. Thus recording a material identity of 5 numeric characters would be represented on the pre-printed form by 5 groups of these 4 soup-bowls. The choices of the limited acceptable alpha characters were all represented by individual soup-bowls. We were advised that shop-floor personnel would not understand this. We argued that anyone who knew how to fill in a pools coupon would soon master it. Trials showed that we were right. Subsequently, once the system was implemented, we only had one failure – a person who was dyslexic.
Date : November 2021
This exhibit has a reference ID of CH67777. Please quote this reference ID in any communication with the Centre for Computing History.
|